Floppyshop 2/Floppyshop - 2.zip/Floppyshop - 2.iso/diskmags/0022-3.564/dmg-0082/75.txt

Text File | 1997-04-16 | 12KB | 265 lines

=========================================================================

INFO-ATARI16 Digest         Sat, 20 Jan 90       Volume 90 : Issue   75

Today's Topics:
                            ARC 6.02 bugs
                      Facts, not only talking a
                    Monitors, Music, Spreadsheets.
                       ST S/ware Rental Places
----------------------------------------------------------------------

Date: 20 Jan 90 19:07:45 GMT
From: cs.utexas.edu!uwm.edu!mrsvr.UUCP!jupiter.uucp![e-mail]
  (Andrew Krieg)
Subject: ARC 6.02 bugs
Message-ID: <[e-mail]>

In article <[e-mail]> [e-mail] (Ray Wallace)
 writes:
>
>It turns out that I can not get ARC 6.02 to work with any of the graphical
>shells I have for ARC (ARCSHELL, ARCGSH21, UNARC). All of them produce either
>Has anyone else had trouble with ARC V6.02 running under these shells? I

ARC 6.02 works fine for me under ARCSHL21.  I don't know if that is the same
as ARCGSH21 that you have listed above.  Mine is the program written by
Charles Johnson.  The latest version I have is from 12/28/89.  I have yet to
experience any bombs.

--
=========================================================================
=       Andrew Krieg                            The Marvel Historian    =
=               G.E. Medical Systems - CT - New Berlin, WI              =
=                    USENET: [e-mail]                   =
=========================================================================
=               "Holy one track Batcomputer mind!" - Robin              =
=========================================================================

------------------------------

Date: 20 Jan 90 20:15:59 GMT
From:
 cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!watserv1!watdragon!tiger!swklassen@
 tut.cis.ohio-state.edu  (Steven W. Klassen)
Subject: Facts, not only talking a
Message-ID: <[e-mail]>

In article <[e-mail]> [e-mail] (RON SHARP)
 writes:
>Phoowie!  The only way I can get simple information on memory locations
>is to become a developer, because anyone else who has the info isn't
>allowed to tell me.
>
>So I can spend $300 U.S. on a giant stack of poorly organized ... stuff.
>And after spending that, maybe I can write some software in my spare
>time (I develop software for the PC at my job) that will garner a few
>bucks, so long as Atari doesn't go down the tubes in the next year.
>
>Forget it!  I'm spending my spare time developing for the PC.  My
>development tools are much better, and I don't have to pay $300 to be
>let into the boys' club, and be told the secrets -- which I have to
>promise not to tell anyone not in the club.  I really do hope that Atari
>smartens up, and creates a new support class short of developer.  (A
>CHEAPER class -- I don't plan to spend $300 on photocopies.)
>
>Flame off!
>---
> ? QNet 2.02: The Crystal Palace * NorthAmeriNet * Toronto [phone] *

Here is a very important hint for the would-be developer.

TRY TO AVOID "DEVELOPING" FOR A GIVEN MACHINE.  When designing software
and writing that initial version, try to keep things portable.  In
other words, try to avoid relying on specific memory locations.  (Remember
that the ST is NOT the c1-Mhz, 16K computer that the Atari 400 was - you
don't have to count bits and clock cycles like you used to.)

The point is, you should try to keep your software so that you can
easily move it to other machines.  There are a number of reasons for
doing this:
        1) If the computer you wrote it on doesn't do well in the
           market you can easily move to one that is doing well.
        2) The more machines you can move it to the larger your
           market will be (ie. a program written for both the IBM
           and the ST will have a slightly larger market than one
           which is limited to one machine or the other.)
        3) You can adapt as technology improves.  (ie. move it to
           an ATW or a Next if you think there is a market for it)

Some things to keep in mind for writing portable software:
        1) Try to avoid machine specific or compiler specific
           routines.  That is, stick to K & R or ANSI C as much
           as you can (or whatever the standards are for the
           language you like).
        2) Avoid specific memory locations whenever possible.  This
           is important as many of these locations may change between
           versions of machines.  If you rely on these locations you
           may find your software no longer works on a new machine.
           (ie. What may have been fine in TOS 1.0 or MS-DOS 2.1 may
           no longer work in TOS 1.4 or MS-DOS 3.2.)
        3) If you must have machine specific stuff (usually for reasons
           of speed) try to keep it separate from the rest of the
           code so that when you need to port to another machine
           you only have to rewrite those sections rather than the
           entire program.
        4) Avoid hard-coding constants into your program.  For example
           if you want 15 lines to be the fixed length of some
           editing program use a
           #define MAX_LEN 15
           or something similar rather than placing the number 15
           through all your code.  This will make things easier to
           change when you move to another machine.

Case in point.  I am currently developing a toolkit for working with
various data structures.  (I'll post more on that in a month or two.)
One of my goals is that I will be able to port it to whatever machine
I find useful for a given task (Someday I hope to have my own small
business, consulting and writing custom systems.  This could often
require changing machines to adapt to the customer.).  Although I am
creating it on a 1040 ST using MWC, I am porting it to Minix-ST to ensure
Unix compatability.  So far I haven't had to change a single line of code
between the two.  If I continue in this trend I will be able to port
my toolkit to whatever machine I want (Next, ATW, Sun, MicroVax, etx.)
without too much trouble.

In conclusion (finally - sorry for the long length, it seemed justified
by some of the comments which have been coming up on the net on
occasion), by avoiding developing for any given machine you can keep
your programs flexible, alowing them to be moved to whatever
environment seems useful for a given project.

While I realize that you often can't be 100% portable (especially if
you need fast graphics) you can often minimize the amount of machine
specific stuff to avoid limiting yourself to one specific machine.


Steven W. Klassen                       +-----------------------------+
Computer Science Major                  | Support the poor...buy fur! |
University of Waterloo                  +-----------------------------+

------------------------------

Date: 20 Jan 90 23:12:07 GMT
From: [e-mail]  (Mark O'Bryan)
Subject: Monitors, Music, Spreadsheets.
Message-ID: <[e-mail]>

In article <[e-mail]> [e-mail] (Jan
 Ameij) writes:
>
> 1) I have a new SM124 which seems to me to be slightly fuzzy, or at any rate
> fuzzier than the one in my office. Before I start asking the dealer about
 this,
> as this is already a replacement for the faulty one first supplied, I thought
> I'd ask "Is there any way of adjusting the beam focus inside the unit?"

Sure, there's a focus knob located inside (labelled "focus").  In my exper-
ience, 5 out of 6 SM124's arrive slightly or substantially misfocused, and
can be improved by adjustment.  Be aware though that optimum focus can not
be obtained simultaneously over the entire screen.  I.e., if the center is
perfect, the edges won't be, and vice-versa.  You'll have to compromise,
but it'll almost always be better than you started with.

Also, be aware that there are dangerously high voltages inside, so you can
kill yourself if you're careless.  You may also void your warranty.  And
be careful when you remove the back, since there's a rather short wire to
the speaker that you'll have to detach.

--
Mark T. O'Bryan                 Internet:  [e-mail]
Western Michigan University
Kalamazoo, MI  49008

------------------------------

Date: 20 Jan 90 22:56:04 GMT
From: uvaarpa!murdoch!astsun8.astro.Virginia.EDU![e-mail]  (Greg Lindahl)
Subject: ST S/ware Rental Places
Message-ID: <[e-mail]>

This shouldn't be here, and it's my fault, but hopefully this,
er, discussion will end here.

In article <[e-mail]> [e-mail] (Rob Demillo) writes:
[ quoting me ]
>>Needless to say, it's extremely rude to call some people pirates
>>because they rent software. Libraries rent books, video stores rent
>>movies. Video stores rent Nintendo carts, which contain software.
>>
>
>Sorry, Greg...I stand by my claim. And the Federal Trade Commission
>stands with me, I'm afraid. (As does STart, BYTE, PC Week, etc. They no longer
>accept advertising from software "rental" places.)

Not all software rental places are pirates. Libraries let you check
out software, are they pirates? Yes, *some* users rent software from
rental places to pirate it. Others don't. If I did rent from such places
(for example, I want to give Maple (costs $400) a test drive for a week
to see if I want to spend that much on it), I'd be extremely offended
if you called me a pirate. And you'd be wrong.

>Your analogies do not hold. If books were as easy to copy as software,
>you can bet there would be similar complaints.

Some books are easy to copy. One of my math textbooks cost $50, and
I could have photocopied it for $10. I guess you'd want the library
to not let me check out such books.

>Computer software is (currently) the *easiest* media to copy - and your
>copy is an *exact* duplicate, not some scratchy re-recording of a record.

Yes. That's why user education is so important. But the US was allegedly
a free country last time I checked, and there is no excuse to prohibit
legit activities.

>Frankly, Greg, I consider it *rude* to steal. I am a professional
>programmer, I work *hard* for my money.

So do I. Do you assume I think stealing is ok because I might want to
rent software? You're wrong.

> If you don't think piracy has wounded
>the software industry - look around.

I never said piracy hasn't hurt the software industry. I think it has.
But education of users is the key, not being rude to random people.

>Atari software, by the way, is acknowledged as being the hardest
>hit.

Please don't start this flamewar again. It was totally non-educational
last time around.

>>In short -- piracy is an issue you deal with by educating users, not
>>by insulting legitimate businesses.
>
>I agree completely.

Good.

> And don't believe I have insulted legitimate
>businesses. If you want to see a piece of software run, go to
>a store and ask the proprieter to start up a copy for you.

Here's where you're wrong. There are pieces of software for the ST that
I can't test in 20 minutes. If I want to demo a piece of MIDI software,
I want to take it home and play with it for several days. Some software
publishers put out demo versions of their software -- that's a great
help. But others do not. Here is a legit market for rentals.

Don't forget the old saw about "Innocent until proven guilty." If
renting software was only used for piracy, I'd think it was a bad
thing. But renting software is useful for legitimate purposes. And I
don't want to get called a pirate because I say renting can be ok.

Have a nice day, but don't tread on me.

Greg Lindahl
[e-mail]                                  Astrophysicists for Choice.

------------------------------

End of INFO-ATARI16 Digest V90 Issue #75
****************************************